WARNING:
JavaScript is turned OFF. None of the links on this concept map will
work until it is reactivated.
If you need help turning JavaScript On, click here.
此概念图以 IHMC CmapTools 创建, 内含信息有关于: 第五章表達系統的鉅觀設計:「總則圖」(Profile Diagram)、「套件圖」(Package Diagram)「互動概觀圖」(Interaction Overview Diagram)、「複合結構圖」(Composite Structure Diagram), 套件圖的基本認識 是 讓我們用一個表達J2SE的JDBC結構的套 件圖來解釋套件圖的基本元素。, 第五章表達系統的鉅觀設計:「總則圖」(Profile Diagram)、「套件圖」(Package Diagram) 「互動概觀圖」(Interaction Overview Diagram)、「複合結構圖」(Composite Structure Diagram) 資料來源根據『UML團隊開發流程與管理』 包括 總則圖, 複合結構圖 包括 信仁醫院住出院系統與其他系統關係 的複合結構圖, 套件圖 包括 信仁醫院住出院系統的套件圖範例, 信仁醫院案例背景描述 緣由 信仁醫院的系統開發非常順利地進行著 ,在「登記出院記錄」的正常流程完成 信仁醫院的使用者測試實際的程式碼後 ,也已經通過驗收。HSDc專案開發人員 決定要讓「登記出院記錄」的使用案例 實作進入第二個「實作循環(iteration), 也就是要加入「替代流程」。」HSDe的 PM、RA、軟體架構師,以及專案開發 人員,針對第二個實作循環要注意的事 項,進行了內部的討論會議。, 問題與分析 是 當然,由於套件圖本身並沒有支援軟體 工程中的「正反向工程」,因此,實際 在程式的寫作上,套件圖並不會真的影 響工程;不過套件圖可以當作是未來開 立專案時的藍圖,可以輔助軟體開發人 員建立專案的「參考」(reference)。, 信仁醫院案例背景描述 是 以下是HSDe軟體架構師與專案設計人員 針對命名空間的討論: HSDe軟體架構師:這次會議主要是討論 有關命名空間的問題,有任何的問題, 歡迎隨時發問 專案設計人員:請問架構師,命名空間 是否要遵循Java的命名原則?利用「com .公司名稱系統名稱」來命名? HSDe軟體架構師:原則上是這樣,不過 我希望在系統名稱之下,再加入一個「 分析類別分類」。 專案設計人員:可不可以舉個例子? HSDe軟體架構師:像「登記出院記錄 BPO」,我就希望放在 「com.hjhospital.hosptiallr·control」的命名 空間下;而其他的領域物件,則放在 「com.hshospital.hospitalln.entity」的命名 空間。 專案設計人員:所以在hospitalln的命名 空間下,應該會有「control」、「entity 」以及「boundary」這三個命名空間囉! HSDe軟體架構師:沒錯,正是這樣。 專案設計人員:這樣我瞭解了。 HSDc軟體架構師:另外,為了簡化原來 的「領域模型」,我希望能夠把三種分 析類別的相依性另外表達。 專案設計人員:對不起,我不大明白你 的意思。 HSDe軟體架構師:也就是説,我希望利 用一張「套件圖」限制住這三種分析類 別的存取範圍。 專案設計人員:這對未來的實作有影響 嗎? HSDe軟體架構師:沒有絕對的影響, 不過這是一個基本的檢核邏輯,未來在 程式實作上會作為我的檢核標準。 專案設計人員:好的,那就等你的套件 圖囉!, 信仁醫院住出院系統與其他系統關係 的複合結構圖 是 根據「5-3-1:信仁醫院案例背景描述 」的情境,HSDc軟體架構師蒐集到了 和信仁醫院住出院系統有關的其他資 訊系統的關係,包括: ■診間系統是住出院系統的「Consumer 」,其有賴「信仁醫院住出院系統」提 供介面供其呼叫。 ■藥品管制系統以及收費管理系統都是 「信仁醫院住出院系統」的Provider,其 提供介面讓「信仁醫院住出院系統」呼 叫。 根據這些蒐集到的資訊,HSDe軟體架構 師所繪製的複合結構圖如下所示, 總結 是 利用UML的「總則圖」可以將團隊開發 中重要的觀念或是技術,用單一的名詞 使用「stereotype」予以整理,讓所有的 團隊成員可以共用這些共同的知識。, 問題與分析 是 如同前面的案例中,HSDe軟體架構師所做 的,就是先把要開發的系統跟外部系統之 間的「主、被動關係」先定義出來。一般 來說,若是要開發的系統是屬於「主動式 」連結外部系統的話,此時,外部系統的 「存取介面」會成為要開發的系統的「限 制」;相反地,如果是屬於「被動式」提 供服務的話,則要開發的系統必須要定義 出標準的「存取介面」,成為其他系統的 限制條件。, 信仁醫院案例背景描述 緣由 信仁醫院住出院系統在經過了結構設計 以及相關細節的討論後,開始進入實際 的程式寫作。HSDe的軟體架構師希望 程式有適當的「命名空間」(Name space)定義。, 複合結構圖 包括 信仁醫院案例背景描述, 信仁醫院案例背景描述 是 HSOcPM:各位,這次的訪談的主要目的 是定義出住出院系統與其他系統的整整合 架構,接下來,我把時間交給我們的架構 師。 HSDe軟體架構師:我想先請問一下,目前 醫院已存在的系統中,有哪幾個系統有可 能和住出院系統有關? 信仁醫院資訊人員:嗯,我們醫院的系統 包括了診間系統、收費管理系統以及藥品 管制系統,這些系統應該都會和住出院系 統有關 HSDc軟體架構師:是否可以定義出這些系 統究竟是「住出院系統」的「Information Consumer」或是「Information Provider」? 信仁醫院資訊人員:我不太瞭解你所説的 意思。 HSDc軟體架構師:也就是説,有哪些系統 會「主動」提供訊息給「住出院系統」, 又有哪些系統會「被動」提供服務給「住 出院系統」? 信仁醫院資訊人員:嗯,是不是有什麼規 則可以依循? HSDe軟體架構師:你可以用醫院的「標準 作業流程」來當作基礎思考。 信仁醫院資訊人員:可不可以説明得更詳 細一點? HSDe軟體架構師:好的,這是我們團隊的 RA根據和貴單位的特助訪談後整理出來的 流程,我在這個流程圖中,標示了幾個可 能可以參考的重點 信仁醫院資訊人員:嗯,看起來沒錯,這 幾個地方的確是會有不同的外部系統參 HSDe軟體架構師:那能不能夠更精確的指 出分別是哪些外部系統呢? 信仁醫院資訊人員:好的。先就「決定病 患住院」來談,在這裡應該會有「診間系 統」參與。看起來,好像是診間系統會通 知住出院管理系統,有病患需要辦理住院 HSDc軟體架構師:太好了!那診間系統就 是「住出院管理系統」的「Consumer」! 信仁醫院資訊人員:喔,原來是這樣啊! 所以在「診療」中,「藥品管制系統」應 該是提供資訊的系統,而「辦理出院」時 ,「收費管理系統」也是提供資訊的 HSDc軟體架構師:這樣來説,針對系統的 Provider以及Consumer都解決了! 信仁醫院資訊人員:嗯。那是不是有關外 部系統的資訊,這樣就可以了呢? HSDe軟體架構師:這只是第一階段,日後 我們在進行程式寫作時,還需要更明確地 定義出「住出院系統」提供給外部的「存 取介面」(Application Programming Interface ,API),以及外部系統所提供的「存取介 面」。所以到時候還是要麻煩你大力幫忙 囉! 信仁醫院資訊人員:喔!我還以為沒我的 事了呢!哈哈哈!, 問題與分析 是 在設計「循序圖」時,有一個原則:一張 循序圖的大小,最好能夠限制在一張「A4 」紙張可以列印的範圍內,最大也不要超 出一張「A3」紙張的列印範圍。一般來說 ,若超過這個範圍的循序圖,通常是無效 的產出!要達成這個目標,建議最好把正 常流程與替代流程分開來繪製不同的循序 圖,再利用「互動概觀圖」把這些流程組 合起來。如此一來,整個設計才不至於失 控,也才能夠達成「有效產出」的目的。, 套件圖 包括 套件圖的基本認識, 問題與分析 是 在過往的軟體設計流程中,大多是利用文件 來規範團對中各個角色人員的職掌與權利義 務範圍;然而,正如同第二章所說,「標準 化文件」一旦隨著時間逐漸流逝往往會變成 「僅具參考價值」;尤有甚者,當團隊成員 對於「標準化文件」的認知不一時,則這份 文件不但沒有幫助,還有可能造成整體開發 上彼此的誤解。, 總則圖 包括 總則圖的基本認識, 問題與分析 是 HSDe軟體架構師把住出院系統下的物件 重新分組,並且利用三個命名空間來擺 放這些設計好的類別,如此一來,就可 以利用命名空間之間的關係圖,來限制 住不同分類物件之間的存取。, 問題與分析 是 一個設計良好的命名空間,可以讓程式 開發人員「望文生義」,並且讓各個命 名空間之間能夠「寬鬆耦合」(loose coupling);而命名空間內的類別,則可以 具備「高內聚力」(high cohesion)。, 總結 是 利用UML的「套件圖」可以表達系統中 ,不同的「套件」、「命名空間」或是 不同的「專案」間彼此的關係。